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Abstract. Traditional denotational semantics assigns radically differ¬ 
ent meanings to one and the same phrase depending on the rest of the 
programming language. If the language is purely functional, the deno¬ 
tation of a numeral is a function from environments to integers. But, in 
a functional language with imperative control operators, a numeral de¬ 
notes a function from environments and continuations to integers. This 
paper introduces a new format for denotational language specifications, 
extended direct semantics, that accommodates orthogonal extensions of 
a language without changing the denotations of existing phrases. An ex¬ 
tended direct semantics always maps a numeral to the same denotation: 
the injection of the corresponding number into the domain of values. In 
general, the denotation of a phrase in a functional language is always a 
projection of the denotation of the same phrase in the semantics of an 
extended language—no matter what the extension is. Based on extended 
direct semantics, it is also possible to construct interpreters for complete 
languages by composing interpreters for language fragments. 


1 The Denotational Specifications of Complex Languages 

A programming language like Scheme [25], Common LISP [32], or ML [19] con¬ 
sists of a rich functional core, augmented by destructive operations on data 
objects, control constructs, and possibly other imperative operators. Traditional 
denotational language specifications [1, 15, 27, 35] cope with these constructs by 
interpreting program phrases as functions that map environments x stores x 
continuations to values x stores. Programmers, however, rely on simpler seman¬ 
tic descriptions when they reason about program phrases. Most program phrases 
do not exploit the full generality of the language, permitting their semantics to 

* The paper is an extended and revised version of Rice Technical Report 90-105, 
“Extended Direct Semantics”, January 1990. 
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No. F196228-91-C-0168 under the direction of Robert Harper and Peter Lee. 
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be analyzed using a simpler semantic model. For example, if a program phrase 
is purely functional and its free variables are always bound to effect-free pro¬ 
cedures, it can be interpreted as a function mapping environments to values. 
Similarly, if an imperative program phrase does not use general control opera¬ 
tors like callcc, goto, or catch and its free variables are always bound to values 
and procedures conforming to the same constraint, it can be interpreted as a 
function mapping environments x stores into values x stores. Unfortunately, 
denotational definitions of practical programming languages are written in a 
form that makes it difficult to extract a simplified definition for a disciplined 
subset—much less prove that the definitions are equivalent over the restricted 
language. 

Another way to describe the same problem is to observe what happens to 
the meanings of simple program phrases like the numeral 5 when a language is 
extended. In a functional language, the numeral 5 denotes what a programmer 
expects: a function from environments to the integer 5. But if we add refer¬ 
ence cells to the language, 5 denotes a constant function from environments x 
stores to values x stores. Moreover, if we add control operators (such as goto 
or callcc), the meaning of 5 becomes a constant function from environments x 
stores x continuations to values x stores. This annoying property of denota¬ 
tional semantics is well-known among language researchers. Indeed, in a recent 
survey paper, Peter Mosses [23] has argued that this phenomenon has been a 
major impediment to the acceptance of denotational semantics as a practical 
vehicle for defining programming languages. 

In this paper, we show how to cast denotational definitions in a form that 
preserves the simple semantics of important language subsets such as the func¬ 
tional core. The simplified definitions for designated subsets are projections of 
the general definition. The new form for denotational definitions consists of a 
trivial base definition and a sequence of extensions. The base definition describes 
a trivial language with exactly two programs: _L, which always diverges, and err, 
which always aborts and reports an error. The extensions all fit within the same 
schema. 

The schema critically relies on the distinction between a complete program 
and a nested program phrase. A complete program is thought of as an agent 
that interacts with the outside world, e.g., a Hie system, and that affects global 
resources, e.g., the store. A central authority administers these resources. The 
meaning of a program phrase is a computation, which may be a value or an 
effect. If the meaning of a program phrase is an effect, it is propagated to the 
central authority. The propagation process adds a function to the effect package 
such that the central authority can resume the suspended calculation. We refer 
to this component of an effect package as the handle since it provides access to 
the place of origin for the package. 

The central authority is implemented via the function admin. It performs 
the actions specified by effects. Actions can modify resources, can examine them 
without changing them, or may simply abort the program execution. Once the 
action is performed, the administrator extracts the handle portion of the effect 
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and invokes it, if necessary. The handle then performs whatever computation 
remains following the action of the effect. Thus, at top-level a handle is roughly 
a conventional continuation. 

Casting a language extension into our framework requires the specification 
of four components: 

— a declaration of the new syntactic constructors for the extension; 

— the definition of a domain of new values, resources, and actions produced by 
the extension; 

— the definition of new clauses in the meaning function M for each new syn¬ 
tactic constructor; 

— the definition of new clauses in the function admin for the new actions. 

In essence, language extensions are determined by adding clauses to the meaning 
function M that describe what value or effect an instance of a new construct 
denotes. New clauses in the function admin determine how actions are interpreted 
as transformations on resources. 

In the second section we motivate our denotational framework based on our 
prior work on operational semantics. We use the third section to illustrate our 
new approach to structuring denotational definitions by presenting an idealized 
dialect of Scheme (Core ML) as the sum of a few extensions to a trivial base 
language. Next we show how to exploit this new technique to write modular 
interpreters in the fourth section. In the fifth section we address two lines of 
related work. Section A of the Appendix defines the notation for domain equa¬ 
tions; Section B contains the pieces of the implementation that are not explained 
in Section 4. 

2 Extensible Operational Semantics 

The intuition underlying our framework of extensible semantic specifications 
is derived from a generalization of the operational semantics of the A-calculus 
to full-fledged Scheme-style programming languages with exceptions, first-class 
continuations, and assignments [9, 10, 11, 12]. The extensions of these seman¬ 
tics are conservative in the sense that the reduction relation for the extended 
language is a superset of the original reduction relation. More precisely, the re¬ 
duction relation for the core language is simply interpreted over the larger syntax 
but is not changed otherwise. The new linguistic facilities are interpreted by the 
addition of new reductions. 

We illustrate our framework for extensible operational semantics by examin¬ 
ing a simple functional programming language, Pure Scheme. Fig. 1 contains the 
complete specification of Pure Scheme’s syntax and reduction semantics. Pure 
Scheme’s term language contains numeric, boolean, and functional constants, 
variables, A-abstractions (user-defined procedures), if-expressions, and applica¬ 
tions. The expression (A x.e) binds x in e. An occurrence of a variable x that 
is not bound by a surrounding A x. is free. An expression is closed if it does 
not contain free variables. If e and e' are expressions, with x possibly free in e, 
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e[x/e'\ is the result of substituting all free occurrences of x in e by e' without 
capturing free variables in the latter. 


Syntax 

c::= 0 | 1 | -1 | 2 | -2 | 

| true | false 

/ ::= zero? | addl | subl 
»: = = c\f 
| x 

| (Ax. e) 

| (if e e e) 

I ( e e ) 

Auxiliary Syntax (Evaluation Contexts) 


( numerals ) 

( booleans ) 

(numeric functions ) 
( constants ) 

( variables ) 

( abstractions ) 

( values ) 

( branching ) 

( applications ) 


::= [ 

(E e) 

(v 

(if E e e) 


(hole) 

(evaluate function position ) 

(evaluate argument position) 
(evaluate test position) 


Standard Reductions 


E[(M 

—► E[8(f, x)] if 8(f, v) is defined 

(«) 

F[((A x. c 

0 »)] 

— E[e[x/v]] 

(/M 

£[(if true ei 

e 2 )] 

— E[e i] 

(iftrue) 

£[(if false ei 

e 2 )] 

— E[e 2 ] 

(iffalse) 


Constant Interpretation 

<5(zero?, 0) = true 
<5(zero?, n + 1) = false 
<5(addl, n) = n -\- 1 
<5(subl, n) = n - 1 


Fig. 1. Pure Scheme and Its Reduction Semantics 


The reduction semantics of Pure Scheme determines a partial function from 
programs to values where a program is a closed expression. There are two sets of 
values: procedures and constants. Following the A-calculus tradition, the spec¬ 
ification of the exa/-function is based on the transitive closure of the standard 
reduction function. The latter is a reduction that partitions any non-value into 
an evaluation context and a redex, reduces the redex, and fills the hole of the 
evaluation context with the contractum. An evaluation context is a special con¬ 
text. The location of the hole in an evaluation context determines which sub-term 
must be evaluated next. Thus, the definition of the set of evaluation contexts for 
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Additional Syntax 


e ::= (ref e) 

(reference allocation ) 


1 (• e) 

(reference dereferencing) 


1 (e := e) 

(reference update (infix)) 


s::= {(*,„)}* 

(store (identifier-value bindings )) 


Additional Auxiliary Syntax 

E ::= (ref E) 

(evaluate sub-expression) 


1 (• E) 

(evaluate sub-expression) 


1 (E := e) 

(evaluate location position) 


1 (v := E) 

(evaluate value position) 


Standard Reductions 

s f?[(ref r)] 

s(l,v) E[l] 

if l is not used in s or E[v\ 

(alloc) 

s(l,v)s’ E[(\ /)] — 

s(l,v)s' E[v] 

(lookup) 

s(l,v)s' E[(l := „')] — 

s(l,v')s' E[l] 

(update) 


Fig. 2. State Scheme and Its Reduction Semantics 


a language defines the order of evaluation. 

In a functional language of Pure Scheme, the evaluation context of a redex 
plays no role until the redex is reduced to a value. For example, the expres¬ 
sion f?[((A *.(addl (if x 0 1))) true)] reduces to E[ 1], no matter what E is. More 
generally, all (closed) expressions in a mathematical language (with recursion) 
either produce a value, signal an error, or diverge. Consequently, a denotational 
semantics can map an expression in such a language to numbers, boolean values, 
functions, errors, or bottom. 

Once Pure Scheme is extended to a language with ML-style reference cells 
(see Fig. 2) 3 the reduction of a closed expression may result in a “stuck ex¬ 
pression” whose future behavior depends on and affects other portions of the 
program. Consider the following expression: 

(ref (A x.x)). 

It is a closed expression that does not diverge, is not a value, and cannot be 
reduced to a value without affecting the context. We refer to such results as 
effects. 


3 The decision to return the location of an update message to the program as the result 
value of the action is arbitrary. ML returns a neutral value (unit), Scheme’s return 
value is undetermined though many implementations return the assigned value. 
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An effect is most easily understood as an interaction between a sub-expression 
and a central authority that administers the global resources of a program. 4 Ex¬ 
amples of such resources are stores, heaps, Hie systems, the place for the final 
result of a program, and other input/output channels. Given an administrator, 
an effect can be viewed as a message to the central authority plus enough in¬ 
formation to resume the suspended calculation. In the operational semantics, 
the “stuck expression”, (ref (A x.xj) in the running example, can play the role 
of the first half of the message; the evaluation context functions as the second 
part of the message. After extending the store, looking up a value, or modifying 
the contents of a location, the calculation process can continue. Technically, the 
operational semantics accomplishes this by filling the evaluation context with 
some datum, which also communicates information from the administrator to 
the suspended expression. By translating this operational semantics into a math¬ 
ematical framework, we can design an extensible denotational semantics for a 
programming language. 

3 Extensible Denotational Specifications 

The denotational specification of a programming language consists of two parts. 
The first part defines the syntactic and semantic domains of the language. 
The domains are sub-domains of some universal domain, e.g., Vlo [29], T“ [24], 
U [28], or T [17]. The syntactic domains specify the phrases of the language; the 
semantic domains contain denotations for the various kinds of syntactic phrases. 
The second part is a functional interpreter that maps elements of the syntactic 
domains to elements in semantic domains. It is defined in a universal 5 program¬ 
ming language like Lambda [29] or KL [17] and satisfies the law of composition- 
ality, i.e., the interpretation of a phrase is a function of the interpretations of its 
sub-phrases. To keep track of the denotations of free variables, interpreters are 
also parameterized over an environment argument. Algebraically speaking, the 
interpreter is (roughly) a homomorphism from syntax to semantics. 

We illustrate the methodology of extensible denotational specifications by 
defining a semantics for Pure Scheme. We first extend this semantics with de¬ 
structive reference cells and then with first-class continuation objects. Although 
Pure Scheme is a simple syntactic language with only one kind of phrase type, it 
is semantically rich and its extensions pose most of the problems that complicate 
traditional denotational language specifications. The first subsection presents the 
general schema of an extensible denotational specification for Pure Scheme and 
its extensions. The second, third, and fourth subsections contain the specifica¬ 
tions for Pure Scheme, State Scheme, and Control Scheme, respectively. The 
latter two are literally enlargements of the semantics of Pure Scheme. The last 
subsection shows that the denotation of a phrase is stable with respect to all 
possible extensions. 

4 It is also possible to design an operational semantics that deals with such resources 
on a more local level [5, 11, 40]. 

5 The language is universal relative to the chosen universal domain. 
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Semantic Domains 

( Values) 

( Computations ) 
(Actions) 
(Errors) 
(Resources) 


V = Zj(V,C) (depends on language) 

C = inV(V) ® inFX((V -► C)j_ ffi A) 

A = inE(E) ® E2 (V, C) (depends on language) 

E={-,err} 

R = 77(V, C, . . .) (depends on language) 


(Environments) 




V 


Semantic Functions 


V : Prog ► ((V ffi E) x R) 

A4 : Expr ► E nv ► C 


V[P\ = admin) JW[P]-,r 0 ) 

Mlnjp = inV(-) = - 
Adjerr ]p = inAC(inE(err)) 

•M[e]p = . . . depends on language . . . 

Auxiliary Semantic Functions 

admin : C x R -► ((V ffi E) x R) 

handler : C -► (V ->■ C) -► C 

inAC : A ->■ C 

admin( —, r) = — 
admin(inV(r), r) = (v,r) 
admin(inFX(A;, inE(err)), r) = (err, r) 

admin(inFX(A;,p), r) = . . . depends on language . . . 

handler) —)/ = — 
handler) inV(r))/ = f(v) 

handler) inFX(A;,p))/ = inFX([Ar : V. handler) k(v))f], p) 
inAC(e) = inFX(inV, e) 


Fig. 3. The Semantic Framework 


3.1 The Semantic Framework: Extended Direct Semantics 

Following the ideas of the previous section, the domain of denotations for phrases 
C consists of two disjoint pieces: the sub-domain of value denotations V and the 
sub-domain of effect messages (effects). The first part of Fig. 3 displays the gen- 
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eral schema for the domain equations. In general, the domain of values is a sum of 
domains constructed from V and C; we indicate this with the notation 27i(V, C) 
in Fig. 3. For a language like Pure Scheme, the domain of values contains num¬ 
bers, boolean values, functions from values to computations, and bottom (the 
denotation of diverging expressions). For State Scheme, the domain of values 
also contains a domain of locations, which interpret reference cells. 

The domain of effect messages is always the product of two domains. The 
first component of this product represents the evaluation context, the other 
specifies the action that the administrator has to perform. A straightforward 
representation of an evaluation context is a function from values to computations, 
which directly corresponds to its operational usage as a function from syntactic 
values to expressions. The action component A of the effect domain is a sum of 
domains built from V and C; in Fig. 3 we use the expression 272(V, C) for this 
purpose. It contains one summand for each kind of action that the administrator 
has to perform. For the trivial base language, the basic domain of actions contains 
only an error action (since we believe that signaling an error is the most basic 
effect). For Pure Scheme, no additional action is required. For State Scheme, 
there are three additional actions: the allocation of a reference cell filled with 
some value, the dereferencing of a cell, and the modification of a reference cell. 

In general, an interpreter maps phrases x environments to computations. 
Environments are needed to interpret the meaning of bound variables. Given 
the schematic domain definitions, an interpreter can deal with two simple pro¬ 
gramming constructs: C2, which represents divergence, and err, which signals an 
error. Other kinds of phrases require an extension of the interpreter. 

Sub-phrases of complex phrases are evaluated via recursive calls to the inter¬ 
preter. Since the result of such a recursive call is a computation, it is necessary 
to inspect the tag of the result. If it is a plain value, the value component can 
be consumed locally. If it is an effect, however, it must be propagated to the 
central administrator, which will interpret its meaning. To deal with this situa¬ 
tion uniformly, we introduce a function handler that maps a computation and 
the consumer of its eventual value to computations. The consumer is a function 
from values to a computation. 6 

The function handler performs a simple tag check: if the first argument is 
in the value sub-domain, it applies its second argument to the value. Otherwise, 
it creates a new effect message that accounts for the additional consumer with a 
modified handle. Thus an effect message is propagated from handler to handler 
until it eventually reaches the central administrator. The administrator, admin, is 
a function of two arguments: a computation and an (open-ended) list of resources 

6 The function handler is roughly a composition combinator for functions from values 
to computations. Let / G V -► V, g G V -► € , and iGV. Then, 

handler) inV(/(r)))(c/) = g{f{x)). 

On a superficial level handler is related to the composition transformation of a 
monad (cmp. Section 5), but it only partially satisfies the monad laws [E. Moggi; 
personal communication, August 1989]. 
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Semantic Domains 

V = inN(Nj_) ® inB(Tj_) ® inP((V C)j_) 
A = inE(E) 

Semantic Functions 


Ad^ra 1 ] = inV(inN(ra)) 

Adjtrue] = inV(inB(true)) 

Ad [false] = inV(inB(f alse)) 

Ad[addl]p = inV(inP(Am : V. 

case to of 

[inN(ra) => inV(inN(n + 1))] 
[m => inAC(err)])) 


Mlxjp = in V(p(z)) 

Ml(\ x. e)]p = inV(inP(A d : V.Ad[e]p[x/d])) 

Ad[(ei e 2 )]p = handler(A4|ei]p) 

(A/ : V.handler(A4[e 2 ]p) 

(A a : V. case / of 

[inP(p) => g(a)] 

[g => inAC(err)])) 

M [(if ei e 2 e 3 )]p = handler(Af |ei]p) 

(At : V. 

case t of 

[inB(true) => Af[e 2 ]p] 
[inB(false) => Af[e 3 ]p] 

[/ => inAC(err)]) 

Fig. 4. An Extended Direct Semantics for Pure Scheme 


(i7(V,C, . . .)). If the computation is a value, the value and the resources are 
returned as the result of the program. A computation that requires an “error” 
action yields the error paired with the current resources. The meaning of a 
program is defined as the composition of the interpreter and the administrator. 

Fig. 3 presents the schema of a general language definition. All of the follow¬ 
ing definitions ht into this schema. Each language fragment demands modifica¬ 
tions of this outline in five places: the sum of value sub-domains (Ti), the sum 
of actions (T2), the list of resources, the clauses of the meaning function A4, 
and the clauses of the administrator function admin. Everything else remains 
the same, e.g., the type of the interpreter, the handler function, the top-level 
meaning function, etc. Since the interpreter maps phrases and environments to 
their meanings, we refer to this style of semantics as extended direct semantics. 
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In the absence of computational effects and errors, the schema actually reduces 
to a schema for direct semantics. 


3.2 Pure Scheme 

We first illustrate the abstract ideas of the first subsection with a simple language 
of arithmetic: 


M ::= r n ] | (addl M) | (subl M) \ . . ., n £ N. 

This language’s value domain only contains the integers and bottom. The effect 
messages only exist to propagate errors. Thus, the domain equations are: 

V = inl(Nj_) 

A = inE(E) 

and the meaning function maps numerals to integers: 

M [ r n 1 ]p = inV(inN(n)). 

The interpretation of an add 1-expression is the result of interpreting its sub¬ 
expression and handling the result with a function that outputs the successor 
for all numeric inputs: 

M [(addl e)}p = handler(A4[e]p) 

(A m : V. case m of 

[inN(n) => inV(inl(n + 1))] 

[m => inAC(inE(err))]) 

For potential non-numerical inputs the consumer function outputs error. Other 
complex expressions are interpreted in the same fashion. 

To extend the language of arithmetic to full Pure Scheme, we add the syntax 
of Fig. 1 and another summand to the domain of values: the domain of procedure 
denotations. Pure Scheme procedures map non-bottom values to computations. 
Thus, the new domain of values is the domain of strict functions from values to 
computations: 

V = inl(Nj_) © inP((V T^ s C) ± ). 

No new effects are required for full Pure Scheme. 

The semantic function (see Fig. 4) maps variables to values and procedures 
to functions in the usual way. For an application (M N) the interpreter first 
recursively determines the meaning of M and coerces it to a value / using 
handler. The corresponding consumer then determines the value a of N in 
a similar manner. The second consumer function applies / to a if / is a function 
and raises an error signal otherwise. 

Booleans and if-expressions require extensions of the arithmetic language that 
are analogous to those described above. Fig. 4 contains the full specification of 
Pure Scheme. 
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Semantic Domains 


V = inN(Nj_) ® inB(Tj.) ® inP((V > C)j_) ffi inL(Lj_) 

A = inE(E) ffi inRef(V) ffi inDer(Lj_) ffi inSet(Lj_ ffi V) 

R = § to 

( Stores ) Sto = U -e^ V 

( Locations ) Lj_ : a flat domain, usually isomorphic to Nj_ 


Semantic Function 


Ad|[(ref e)]p = handler(.A/([]e]]p)(A v : V.inAC(inRef (u))) 
A4[(ei := e 2 )]p = handler(A<[ei]p) 

(XI : V.handler(Ad|[e2]p) 

(A a : V. case l of 

[inL(l') => inAC(inSet(l', a))] 
[g => inAC(inE(err))])) 

M\(\ e)]p = handler(Ad[e]p) 

(XI : V.case l of 

[inL(l') => inAC(inDer(l'))] 

[g => inAC(inE(err))])) 


Administrator Function 

admin(inFX(£;, inRef(r)), r) = admin(£;(inL(new(r))), extend(r, new(r), v)) 
admin(inFX(£;, inSet(l, v)), r) = admin(£;(7), extend(r, l, v)) 
admin(inFX(A;, inDer(l)), r) = admin(A;(lookup(r, /))), r) 


Fig. 5. An Extended Direct Semantics for State Scheme 


3.3 State Scheme 

The addition of reference cells to Pure Scheme requires the syntax of Fig.2 and 
a new class of values for the interpretation of reference cells. Following tradition, 
we call these values locations. Locations are bound in the store (S to), which is a 
part of the global resource pool. Like all other resources, the store is managed by 
the administrator. Thus, the creation of a cell requires a message to the central 
administrator. It allocates a new location and associates it with the value of the 
allocation message. The result of the allocation is the new location /, that is, the 
administrator uses the handle to return l to the program. Similarly, the acts of 
dereferencing and modifying the contents of a cell also require an exchange of 
messages between the program phrase and the administrator. 

Translated into the language of our denotational framework, the definition 
of State Scheme requires a new summand for the domain of values, the domain 
of locations, and three new summands for the domain of actions, the second 
component of effect messages: 
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1. inRef(V), which represents an allocation message; 

2. inSet(Lj_, V), which represents an update message; and 

3. inDer(Lj_), which represents a dereferencing message. 

Moreover, the list of resources (thus far empty) needs to be extended with a 
store. See the first part of Fig. 5 for the detailed specification of the extended 
domains. 

The interpretation of the three new syntactic forms is straightforward. For 
each form, the interpreter recursively determines the computation of the sub¬ 
expressions with a handler that eventually issues an effect message concerning 
the allocation, modification, or dereferencing of a location. The extended admin¬ 
istrator accepts precisely these three new effect messages. If the effect message 
is an allocation message, it proceeds as described at the outset of this section. 
The other two effect messages are treated in a similar vein. The second part of 
Fig. 5 presents the new clauses for the interpreter and administrator functions; 
the clauses in M and admin for Pure Scheme syntax and effect messages remain 
the same! 


Syntax 


e ::= (catch x e) | (throw x e) 


Semantic Domains 

V = inN(Nj_) ® inB(Tj.) ® inP((V C)j_) ffi inK((V C)j_) 
A = inE(E) ffi inCon(((V -► C) -► C)j_) 

Semantic Function 


Ad[(catch x e)]p = inAC(inCon(A k : V -► C.handler(Ad[e]]p[:r/inK(£;)]) k)) 

Ad [(throw x e)]p = handler(Ad[e]p) 

(A?) : V. case p(x) of 

[inK(Ar) => inAC(inCon(A k' : V -► Ci(ti)))] 

[k => inAC(inE(err))]) 


Administrator Function 

admin(inFX(A;, inCon(/)), r) = admin(/(A;), r) 


Fig. 6. An Extended Direct Semantics for Control Scheme 


3.4 Control Scheme 

Standard Scheme and SML of New Jersey provide constructs for programming 
with first-class continuation objects. A continuation object is an abstraction of 
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the control state of a program. Gaining access to this control abstraction is often 
called catching a continuation. Using this abstraction, or throwing to a contin¬ 
uation in the jargon of Scheme and SML, a program can discard its current 
continuation and transmit a value to a previously caught continuation object. 
Control Scheme employs the syntax (catch x e) for catching the continuation 
and binding it to x and the syntax (throw x e) for throwing the value of e to the 
continuation bound to x [37]. 7 Modeling first-class continuation objects accord¬ 
ing to the traditional method requires the use of a continuation-semantics [36, 
1, 15, 27, 35]. A continuation semantics parameterizes the denotation of every 
phrase type over a continuation, which is a function that maps intermediate 
results to final answers. 

In the framework of extended direct semantics the output of the final answer 
is under the control of the central administrator. Sending an effect message from 
any place in the program to the administrator by definition constructs a handle, 
which is a functional abstraction of the rest of the computation. Hence contin¬ 
uation objects are easily accommodated in the framework. A catch-expression 
denotes an effect message that contains the recipient of the continuation, which 
is roughly the body of the catch-expression (e) parameterized over the name for 
the continuation object (x). The administrator applies the recipient to the han¬ 
dle relinquishing control over the rest of the computation. A throw-expression 
denotes a similar package but the continuation recipient of the package ignores 
the continuation it receives from the administrator and uses the object bound 
to the throw variable instead. 

With regards to domains, the extension of Pure Scheme to Control Scheme 
requires the addition of one value summand, the domain of continuations, and 
one effect, a control message. The latter contains the recipient of the continu¬ 
ation, which is a function from handles to computations. The extension of the 
meaning function M and the administrator admin implement the above schema. 
The details are given in Fig. 6. 

Extending State Scheme to Core Scheme, a Scheme-like language that con¬ 
tains reference cells as well as catch and throw, is similarly easy. It is necessary 
to extend the domains of State Scheme as follows: 

V = inN(Nj_) © inB(Tj_) 0 inP((V _L—> C)j_) 0 inL(Lj_) 0 inK((V i_—> C)j_) 
A = inE(E) 

0 inRef(V) 0 inDer(Lj_) 0 inSet(Lj_ 0 V) 

0 inCon(((V _L—> C) _L—> C)j_) 

The new clauses for the meaning function M and the administrator admin re¬ 
main the same. 

The merger of State Scheme and Control Scheme is symmetric. Merging the 
reference domains into the domains of Control Scheme yields domains that are 
isomorphic to those of Core Scheme. The resulting meaning function and the 

7 With first-class continuations objects it is easy to simulate many other control con¬ 
structs and patterns, e.g., loop exits, blind and non-blind backtracking [14], corou¬ 
tines [16], light-weight threads [39], and time-preempted computations [8]. 
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administrator would be identical to the ones we just described. In general, the 
addition of new orthogonal linguistic constructs is as straightforward as the ex¬ 
tension of Pure Scheme to Control Scheme or of State Scheme to Core Scheme. 
It requires the addition of summands in the domain of values, the domain of 
effects, the interpreter and the administrator function. No modification of the 
previous specifications is needed. We therefore believe that the attribute “ex¬ 
tensible” is fully justified for our new style of denotational specifications. The 
following subsection provides the basis for a more formal justification of this 
attribute. 


3.5 Stable Denotations 

Recall that the semantic domains for an extended direct definition have the form 
( Values) V = S 1 (V,C) 

(Actions ) C = inE(E) © A 2 (V, C) 

(Resources) R = I7(V, C,...) 

where Ti(V, C) and ^(V, C) are disjoint sums of terms constructed using do¬ 
main operations and subsets of V and C. An orthogonal extension of a semantic 
definition written in this framework consists of six parts: 

— a set of syntactic constructors defining the syntax of the extension; 

— a collection of new values designated by new terms in the sum Ai(V, C); 

— a collection of new actions designated by new terms in the sum ^(V, C); 

— a new clause in the meaning function M for each new syntactic constructor; 

— a new component of the list of resources; 

— a new clause in the admin function for each new kind of action. 

Any of these components except the first can be omitted. 

By the form of the domain specifications, the semantic domain for a language 
extension is a superset of the semantic domain for the original language. The ex¬ 
tension process adds new elements to the semantic domain. More precisely, there 
are two pairs of functions that relate the original domains V, C to corresponding 
enlarged domains V', C'. First, there is a pair of functions <Pyj_-^V' : V i_—> V' 
and @cl-^C '■ C -L—> C', that inject values and computations from the smaller 
domains to the values and computations in the larger domains. These injections 
are actually identities (interpreted on the universal domain). Second, there is a 
pair of functions : ^' -L—> V and ?Fc'J_-^C : C 7 _L—> C, that project the 

values and computations from the larger domains onto values and computations 
of the smaller domains. These projections map any components of values and 
computations with new tags to !_ and leave all other components unchanged. In 
summary, 


° $v'_L-^V — ^V'_L-^V E A/' an d ^V_L-^V' : 


° S'CT-.C = ^C'1-.C E Ic and <£cj_->C' = Ic ■ 


hC-L-C' 
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(define-const-structure (Loop)) 

(define-const-structure (Err)) 

(define baseM 

(module (Interpreter Admin Resources) 

(define Interpreter 
(lambda (exp env) 

(match exp 

[($ Loop) (printf "looping~n") (Interpreter exp env)] 
[($ Err) (mExc ’error)] 

[exp (error ’Interpreter "can't interpret ~s" exp)]))) 

(define Admin 

(lambda (comp resources) 

(match comp 

[($ Val v) (cons v resources )] 

[($ FX continuation ($ Exc n)) 

(error ’Admin "exception raise:~~s~n" n)] 

[else (error ’Admin "bad effect message: ~s" comp)]))) 

(define Resources ’()) )) 


Fig. 7. Module for Base Language 


where lx is the identity function on the domain X. 

Informally speaking, this property asserts that in the framework of extensible 
semantics, the addition of a programming construct corresponds to the addition 
of a new “dimension” to the space of meanings. This addition satisfies the fol¬ 
lowing property. Let M be the meaning function for the core language, and let 
M' be the meaning function of an arbitrary extension. If e is an expression in 
the core language, p an environment in Var _ls-> V, and p' in Var _ls-> V', then 

Ad[e]p = ° P)) 

^C±^C'(- A/ *[ e K ,Z Vj_^V ° p')) E M'{e\p', 

The reader may want to contrast this general statement with the numerous 
papers on the relationship between direct and continuation semantics [13, 18, 
26, 30, 34], 


4 Composing Interpreters 

Given an extended direct semantics of Core Scheme, we should be able to imple¬ 
ment an interpreter for Core Scheme in a modular fashion. One obvious possibil¬ 
ity is to concatenate the domain summands and the clauses of the functions M 
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;; Syntax: e ::= (var x) | (lam x e) | (app e e) 

(deflne-const-structure (var xj) 

(deflne-const-structure (lam x M )) 

(deflne-const-structure (app M N)) 

(define CBVM 

(lambda ( language ) 

(import ([language (InterpPrev Interpreter) Admin Resources ]) 

(module (Interpreter Admin Resources ) 

;; Semantics: V = Proc(E —»■ C ) 

(define-const-structure (Proc closure )) 

(define inProc make-Proc) 

(define Interpreter 
(lambda (exp env) 

(match exp 
[(* ™r *) 

(inVal (env r))] 

[($ lam x exp ) 

(inVal (inProc (lambda (v) (InterpTop exp (Extend env x r)))))] 
[($ app expl exp2) 

(Handler (InterpTop expl env) 

(lambda (/) 

(Handler (InterpTop exp2 env) 

(lambda (a) 

(match / 

[($ Proc g) (g a)] 

[. (mExc ’error)])))))] 

[exp (InterpPrev exp emi)]))))))) 


Fig. 8. Module for Call-by-Value Lambda Notation 


and admin. This method yields monolithic interpreters defined from independent 
pieces, but the method for gluing them together is based on program text and 
is thus beyond the scope of most programming languages. 

One alternative is to use an object-oriented programming language in the 
spirit of CLOS [6]. Each language fragment would extend the list of resources, 
and the interpreter and administrator methods of an existing language. In addi¬ 
tion a language fragment would also introduce new local data constructors. 

Here we present another alternative based on the module system of Rice 
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Scheme. 8 It is inspired by Steele’s upcoming paper on composing monads [33]. 9 
Fig. 7 through Fig. 14 in this section and Section B contain the complete code. 
A language is implemented as a module that exports three bindings: 

1. an interpreter function; 

2. an administrator function; and 

3. a list of resources. 

The basic language module in Fig. 7 interprets two constants, Err and Loop, 
with obvious meanings, implements the administrator of Fig. 3, and exports an 
empty list of resources. 

Each language fragment consists of a Hie with two parts. The first part is 
a set of (abstract) syntax constructors. The syntax constructors are global for 
ease of access for the interactive user of the language. The second part is a lan¬ 
guage transformer, a function that maps a language implementation to a richer 
language implementation. The interpreter functions in language transformers 
include a clause for each new syntactic facility that the language fragment intro¬ 
duces. When the local interpreter function interprets a sub-expression, it must 
call the interpreter for the complete language since sub-expressions may contain 
facilities from a language fragment that is yet to be added. Similarly, the local 
administrator of a language transformer must deal with all new resources and 
effects that the transformer introduces. But again, it must call the administra¬ 
tor for the complete language after the action is performed such that all possible 
computations can be administered. 

For a typical language fragment, consider Fig. 8, which defines the inter¬ 
pretation of the call-by-value A-notation of Pure Scheme. The signature of the 
language transformer is 
(CBVM : ((module 

(Resources R) 

( Admin (C^, x R _L—> V x R)) 

( Interpreter (exps x E nv _L—> C))) 

-L—> 

(module 

(Resources R) 

( Admin (C^ x R _L—> V x R)) 

( Interpreter ( exps x E nv _L—> C))))) 

where = V ® ((V i_—> C) (g) E). That is, the administrator only handles the 
basic computations, returning a value and an error. Once the resulting language 
module is fed into the language transformer for the control language, this will 

8 Rice Scheme is an extension of Chez Scheme [7] that includes modules and data 
constructor definitions for immutable structures. It also comes with a soft type sys¬ 
tem [41] that infers types and eliminates type checks where possible. Our implemen¬ 
tation of Core Scheme type-checks statically and is thus independent of a run-time 
tag checking. 

See the next section for a brief comparison with his technique. 
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;; Syntax: e ::= (catch x e) | (throw x e) 

(deflne-const-structure (catch x Mj) 

(deflne-const-structure (throw x N)) 

(define controlM 

(lambda ( language ) 

(import ([language (InterpPrev Interpreter) (AdminPrev Admin) Resources ]) 
(module (Interpreter Admin Resources) 

;; Semantics: V = K(V -► C); C = FX(C-► C, Con(F-► Cj) 

(define-const-structure (K v->c)) 

(define inK make-K ) 

(define-const-structure (Con v->c)) 

(define inCon (lambda (x) (inCC ( make-Con r)))) 

(define Interpreter 
(lambda (exp env) 

(match exp 

[($ catch x exp) 

(inCon 

(lambda (k) 

(Handler (InterpTop exp (Extend env x (inK kjj) A;)))] 

[($ throw x exp) 

(Handler (InterpTop exp env) 

(lambda (v) 

(match (env x) 

[($ K k) (inCon (lambda ( kp ) ( k r)))] 

[. (mExc ’error)])))] 

[exp (InterpPrev exp em>)]))) 

(define Admin 

(lambda (comp resources) 

(match comp 

[($ FX continuation ($ Con r j) 

(AdminTop (r continuation) resources )] 

[comp (AdminPrev comp resources)]))))))) 


Fig. 9. Module for Catch and Throw 


change. The signature for the latter transformer clearly shows this transforma- 
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(controlM : ((module 

(Resources R) 

(Admin (C^ x R _L— > V x R)) 

(Interpreter (exps x E nv _L— > C))) 

_L-^ 

(module 

(Resources R) 

(Admin (C c x R _L— > V x R)) 

(Inierpreier (exps x E nv _L—> C))))) 

(where C c = V®((V _L-^ <C)®(E®((V _L-^ C) _L-^ <C))). Now the administrator 
also handles control messages, according to the specification in Fig. 6. For the 
rest of the language implementation, including the definition of the value con¬ 
structor, of Handler and of environments, we refer to Section B in the appendix. 

Finally, the implementation of the complete language consists of four defini¬ 
tions: 

1. the module for the complete language, defined by composing language frag¬ 
ments functionally and applying them to the base module; 

2. a global definition for the interpreter of the complete language; 

3. a global definition for the administrator of the complete set of resources; and 

4. a meaning function for programs. 

Here is the definition for Core Scheme: 

(define CoreScheme (storeM (controlM (CBVM (arithmM baseM))))) 

;; The global interpreter: 

(define InterpTop (import ([CoreScheme Interpreter ]) Interpreter )) 

;; The complete administrator 

(define AdmmTop (import ([CoreScheme Admin]) Admin)) 

;; The Program Meaning Function: 

(define Program 

(import ([CoreScheme Resources ]) 

(lambda (P) 

(AdmmTop (InterpTop P Empty) Resources)))) 

The order of function composition in the definition of CoreScheme is irrelevant; 
omitting a language fragment in the chain defines a sublanguage of Core Scheme 
without the respective constructs. 

5 Related Work 

Monads. Moggi’s [21, 22, 20] recent work on formulating notions of computa¬ 
tions as monads, popularized by Wadler [38], is partly motivated by the lack of 
modularity in denotational specifications and a resulting lack of understanding of 
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the logical relationships between computations. Roughly speaking, a monad cor¬ 
responds to a triple consisting of a domain constructor T that maps a domain of 
values to a domain of computations, an injection ry from values to computations, 
and a combination transformation fj, for computations. Different monads express 
different styles of denotational specifications and thus computations. Some typ¬ 
ical monads are the store-passing monad, the continuation-passing monad, and 
the monad for non-deterministic calculations. 

Paremeterizing denotational direct models over monads leads to more flexi¬ 
ble language specifications. The parameterized domain equation of a “monadic 
semantics” is 


V = N ± © (V _L-^ S T(V)); 

the meaning assignment for numerals maps a numeral to its injection into the 
computation domain: 

M^n'lp = ry(n). 

Now, if T(V) = (V -L—> A) _L—> A for some fixed domain A and 
,( n )=il:VAAI( n ), 


then the semantics is a continuation semantics. If T(V) = §to _L—> (V ©S to) and 


11 (n) = Xa:Sto.(n,a), 


then instantiating the semantics yields a store-passing semantics. In general, 
given a direct semantics parameterized over a monad, it is easily possible to 
move to a semantics based on a different style, but as a result, a numeral is 
assigned different domain elements—depending on the chosen monad. 

Unfortunately, the combination of monads poses severe difficulties. Since 
monads cannot be composed directly, Moggi [20:ch.4] introduced the notion of a 
monad constructor, which are roughly monad transformers and can be combined. 
Combining the same two monad constructors in a different order, however, often 
yields different results. A typical example is the combination of an exception 
monad with a store monad. One combination undoes side-effects in the process 
of raising an exception, the other one does not. 

To overcome the problems associated with combining monads, Steele [33] 
introduces the idea of a pseudo-monad, a relaxation of Moggi’s notion. Based 
on the functional composition of pseudo-monads, Steele shows how to build 
interpreters for languages from interpreters for language fragments. Section 4 
was inspired by his approach. But pseudo-monads have the same problems as 
monads: denotations are still not stable and combinations are not symmetric. At 
this point it is not clear what the trade-offs between the monad approach and 
our approach are. 
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Vienna School of Denotational Semantics. The extended direct semantics for 
Control Scheme is related to the approach of the Vienna School of Denotational 
Semantics [3, 4, 15:52-55] to modeling jumps and labels, a method that was 
partially rediscovered by Allison [2]. Indeed, the treatment of labels and gotos 
in block-structured languages according to this school of thought can be seen as 
an instance of our technique. In their framework, a statement denotes a state 
transformer that either returns a new state or a syntactic label (combined with 
a state). Returning a state corresponds to returning a value; returning a label 
is an effect message. The responsibility of propagating effects rests with the 
composition function for statements and other “glue” functions. When a label 
reaches the top-level, an exception handler that corresponds to our administra¬ 
tor effects the appropriate jump. Blikle and Tarleki [4] showed that by using the 
VDM technique, denotational specifications can use sets instead of domains and 
partial functions, instead of continuous ones. The Vienna School has not ap¬ 
plied this technique to the specification of other imperative language constructs 
[D. Bjprner; letter, June 5, 1990]. 

6 Conclusions 

Extended direct semantics is a new method for formulating denotational spec¬ 
ifications of programming languages. Unlike the conventional approach, a lan¬ 
guage specification based on extended direct semantics is easily extensible with 
orthogonal language constructs. Most importantly, the extensions preserve the 
denotations of phrases in the core language. 

Even though our illustration concentrates on extensions of functional lan¬ 
guages, imperative languages can be specified in a similar fashion. A denotational 
model of an Algol-like language would be easy to construct. Indeed, the model 
may be closer to an implementation given that the store is a central resource 
rather than a first-class object that is passed around. 

A more comprehensive comparison of the two approaches to denotational 
specifications will have to address several questions. First, we should investi¬ 
gate whether extended direct models characterize languages as precisely as the 
alternative continuation and store semantics, that is, we should check whether 
the new models have different full abstraction properties. 10 Second, we need to 
understand what implementation advantages each approach offers. Finally, we 
should study the design of modular logics for languages since the raison d’etre 
for a denotational semantics is its usefulness in reasoning about programs. 
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and have published a report on the results [31]. 
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A Notation for Domain Specifications 

The semantic definitions presented in the paper rely on the domain constructors 
® (smash product), ® (coalesced sum), -j_ (lifting), _L— > (continuous functions), 
and _ls-> (finite continuous functions). In this appendix, we briefly describe each 
of these constructions and associated notation. 

The domain operators ®, ® , and -j_ are defined by the following equations: 

A ® B = {(a, 6) | a E A, b E B, a yl _L, b yl J_} U {J_} 

A ® B = {(true, a) | a E A \ {J_}} U {(false, b) \ b E B \ {J_}} U {J_} 

A± = {-L} U {(true, a) | a E A} 

The values true and false are used as “tags” in the construction of composite 
objects; the objects (true, a) and (false, a) are distinct from J_ regardless of the 
value of a (including a = J_). The notation 


inA(A) ® inB(B) 
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denotes exactly the same domain 


A © B ; 


the tags inA and inB implicitly define the functions inA : A _L—> A © B and 
inB : B _L—> A © B where 


inA(«) = 


(tr 


if * e A 

otherwise 


inB(a:} 


(false, x) if * £ B 
© otherwise 


Finally, the notation 


inA(A) 


has exactly the same meaning 


inA(A) © in<Z>(<Z>) 


where is the domain containing only the divergent element _L. 

The binary domain constructions © and © obviously generalize to any finite 
arity n > 2. In this case, we use n distinct tags such as the numbers 1,2, , nTl. 

The n-ary product of Ai, . . ., A n is written 

Ai © ... © A n . 


Similarly, the n-ary sum of Ai, . . ., A n with injections inAi, . . ., inA n is written 
inAi(Ai) © ... © inA n (A n ). 

Since the choice of tag values in sums is arbitrary, we use pattern match¬ 
ing notation to identify components of a sum. It also provides a convenient 
mechanism for projecting a sum onto a component domain. Given the sum 

inAi(Ai) © ... © inA n (A n ), 


the expression 


case y of 

[inAi(*i) => ei] 


[inA n (©0 => e n])) 

means: 

if y has the form inAi(*i), then ei 
else . . . 

else if y has the form inAi(*i), then e n 
else _L. 

Each subexpression e; can contain the variable X{ as well as any variables bound 
in the context enclosing the case expression. 

The domain A _L—> B is the set of all continuous functions / : A _L—> B such 
that /(|_| X) = \_\f(X) for all chains X. The domain of continuous functions 
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is ordered by set inclusion (viewing functions as sets of ordered pairs). The 
notation A x : A.e : B defines the anonymous function f(x) = e : A _L—> B. 

A _L-^ S B denotes the domain of strict functions from domain A to domain 
B. A function in the domain A _L—> B is strict if /(_L^) = Tg. 

The finite function domain construction A _ls-> B is defined only for flat 
domains A: 

A _!©-> B = {S'eAxB|S'is finite, S e A _L-^ S B} 

Given two Hnite functions /, g £ A _!©-> B, / C g if either (i) f is 1 or (ii) f 
and g have the same domain D and for all d E D, f(d) C g(d). We frequently 
interpret elements of A _Le-e B as functions in A _L—> B. 

B The Store Module and Global Definitions 

This section presents the remainder of the modular interpreter for Core Scheme. 
Figs. 10 and 11 contain the global definitions, i.e., the definition of the handler 
and of functions dealing with environments. Fig. 12 is the language fragment 
that deals with arithmetic; a similar fragment for boolean expressions was omit¬ 
ted for space reasons. Finally, Fig. 14 (Parts 1 and 2) presents the reference cell 
module. 


;; Semantic Framework: 

;; V = - 

;; C = Val(G) + Comp(G —»■ C, Exc) 

(define-const-structure ( Veil Numjn )) 

(define inVal mcike-Vcil ) 

(define-const-structure (FX V->C Receiver )) 

(define inCC (lambda (x) ( make-FX inVal x))) 

(define-const-structure ( Exc num)) 

(define inExc (lambda (x) (inCC (make-Exc x)))) 

(define Handler 

(lambda (computation consumer ) 

(match computation 

[($ Val v) (consumer r)] 

[($ FX continuation request ) 

(make-FX 

(lambda (x) (Handler (continuation x) consumer )) request)]))) 


Fig. 10. Global Definitions 
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;; Environments: 

(define Empty 
(lambda (x) 

(error ’env "Impossible: an open program ~s" a;))) 

(define Extend 

(lambda (env x v) 

(match x 

[(? symbol?) (match-lambda [(? symbol? y) (if (eg? x y) v (env y))])] 
[else (error ’Extend "not a variable: ~s" a;)]))) 


Fig. 11. Environments 


;; Syntax: e ::= (int n) | (addl e) | (subl e) 

(define-const-structure (int n)) 

(define-const-structure (addl M )) 

(define-const-structure (subl M j) 

(define arithmM 

(lambda ( language ) 

(import ([ language (InterpPrev Interpreter ) Admin Resources ]) 
(module (Interpreter Admin Resources ) 

;; Semantics: V = Num(rartm) 

(define-const-structure (Num num)) 

(define inNum make-Num) 

(define Interpreter 
(lambda (exp env ) 

(match exp 

[($ int m) (in Val (inNum m))] 

[($ addl exp) (Handler (InterpTop exp env) (op addl))] 
[($ subl exp) (Handler (InterpTop exp env) (op subl))] 
[exp (InterpPrev exp em>)]))) 

(define op 
(lambda (/) 

(lambda (n) 

(match n 

[($ Num m) (in Val (inNum (f m)))] 

[- (inExc ’error)])))))))) 


Fig. 12. Module for Arithmetic 




Matthi 


;; Syntax e ::= (ref e) | (deref e) | (setref e e) 

(define-const-structure (ref x)) 
(define-const-structure (deref M)) 
(deflne-const-structure (setref M N)) 

(define storeM 

(lambda ( language ) 

(import ([language 


;; C = FX(F-> C, Ref(F) + Der(i) + Set(i, V)) 

(define-const-structure ( loc num j) 

(define inLoc make-Loc ) 

(define-const-structure ( Ref r)) 

(define inRef (lambda (r) (inCC ( make-Ref xjjj) 

(define-const-structure ( Der l )) 

(define inDer (lambda ( l ) ( inCC ( make-Der 1)))) 


(define inSet (lambda (l v) (inCC ( make-Se 


(define Interpreter 
(lambda (exp env) 

(match exp 

[($ ref exp) (Handler (InterpTop exp env) inRef 
[($ deref exp) 

(Handler (InterpTop exp env) 

(lambda (r) 



(Handler (InterpTop expl env) 
(lambda (l) 

(Handler (InterpTop exp2 er 
(lambda ( v ) 

(match l 

[($ loc I) (mSet l r)] 
[. [inExc ’error)])))))] 
[exp (InterpPrev exp em>)]))) 


Fig. 13. Module for Refe: 
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(define Admin 

(lambda (comp resources ) 

(let ([store (ExtractStore resources )]) 

(match comp 

[($ FX continuation ($ Ref v)) 

(AdminTop (continuation (inLoc (new store))) 

(cons ( make-StoreRes (cons (cons (new store) v) store)) 
resources ))] 

[($ FX continuation ($ Der l )) 

(AdminTop (continuation (lookup store l)) resources )] 

[($ FX continuation ($ Set l v)) 

(AdminTop (continuation (inLoc l)) 

(cons (make-StoreRes (update store l c)) resources ))] 
[comp (AdminPrev comp resources)])))) 

(define-const-structure (StoreRes s)) 

(define Resources (cons (make-StoreRes ’()) ResPrev )) 

(define ExtractStore 
(lambda (resources) 

(match resources 

[(($ StoreRes s) . res) s] 

[(_ . res) (ExtractStore res)] 

[’() (error ’Extract "impossible")] ))) 

(define new length ) 

(define lookup 

(lambda (store l) 

(let L ([store store]);; assq yields less precise types 
(match store 

[((( ? number? m) . v) . s) (if (= m 1) v (L s))] 

[’() (error ’lookup "impossible")])))) 

(define update 

(lambda (store l v) 

(match store 

[(((? number? m) . u) . s) 

(if (= l m) 

(eons (eons l v) s) 

(cons (cons m u) (update s l u)))] 

[’() (error ’update "impossible")]))) )))) 


Fig. 14. Module for Reference Cells: Part 2 
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